home *** CD-ROM | disk | FTP | other *** search
/ ftp.cs.arizona.edu / ftp.cs.arizona.edu.tar / ftp.cs.arizona.edu / icon / newsgrp / group01a.txt / 000039_icon-group-sender _Tue May 30 12:07:40 2000.msg < prev    next >
Internet Message Format  |  2002-01-03  |  2KB

  1. Return-Path: <icon-group-sender>
  2. Received: (from root@localhost)
  3.     by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id MAA19353
  4.     for icon-group-addresses; Tue, 30 May 2000 12:06:08 -0700 (MST)
  5. Message-Id: <200005301906.MAA19353@baskerville.CS.Arizona.EDU>
  6. From: "F.G. van DORP" <F.G.van.Dorp@digimedia.nl>
  7. X-Newsgroups: comp.lang.icon
  8. Subject: Re: CODE() and  @/2
  9. X-Newsreader: Forte Agent 1.7/32.534
  10. Date: Tue, 30 May 2000 18:55:33 GMT
  11. X-Complaints-To: abuse@chello.nl
  12. X-Trace: flipper 959712933 212.187.67.243 (Tue, 30 May 2000 20:55:33 MET DST)
  13. To: icon-group@optima.CS.Arizona.EDU
  14. Errors-To: icon-group-errors@optima.CS.Arizona.EDU
  15. Status: RO
  16. Content-Length: 1209
  17.  
  18. On 26 May 2000 11:38:34 -0400, Steve Wampler <swampler@noao.edu> wrote:
  19.  
  20. >"F.G. van DORP" wrote:
  21. >> 
  22. >...
  23. >> Can  somebody please explain the infix @ operator  ?
  24. >> The closest I can get  is something like:  @'s first argument gets  pushed
  25. >> onto its second argument's  stack  before the latter is activated....
  26. >>...
  27. >
  28. >So, each co-expression sees @ as an operator that "invokes" another
  29. >co-expression
  30. >to produce a result.  The result can be produced in one of two ways:
  31. >
  32. >(1) Since a co-expression is an expression, and since all expressions in Icon
  33. >    produce results, there is an implicit transfer of the result of that
  34. >    expression back to the invoking co-expression.  This is how most people
  35. >    use co-expressions, as in:
  36. >
  37. >       nextLabel := create "L" || seq()
  38. >
  39. Thanks for replying.
  40. I tried
  41.  
  42.        nextLabel := create "L" || (1 to 10) || ("foo" @ &source)
  43.        write(@nextlabel)
  44.         ....
  45.  
  46. and to my very surprise it did act as a regular RETURN (no
  47. ASSEMBLER jargon necessary after all), writing
  48.  
  49.       L1foo
  50.       ....
  51.  
  52. Unfortunately results are quite unpredictable: either some aren't
  53. written at all, or Win32 preempts further execution with an "illegal
  54.  operation" error.
  55. >  
  56.  
  57.